Newsletters: add 98 (2020-05-20)#402
Conversation
| There's no need[^getheaders-details] to send more than one `getheaders` | ||
| request and Bitcoin Core doesn't send more than one block announcement | ||
| in an `inv` message, so this change should have no effect on Bitcoin | ||
| Core nodes who connect to Bitcoin Core peers; it's only expected |
There was a problem hiding this comment.
suggestions:
- s/who/that/
- s/it's/its/ (or "the")
|
|
||
| - [Eclair #1395][] updates the route pathfinding used by Eclair to | ||
| factor in channel balances and to use [Yen's algorithm][]. Testing | ||
| quoted in the PR description says, "The new algorithm consistently |
There was a problem hiding this comment.
"Testing" seems awkward as a subject.
| elegance] the "elegance" of a simplified version of the protocol | ||
| that uses three transactions. Dmitry Petukhov [posted][petukhov | ||
| tla+] about a [specification][sas tla+ spec] he'd written for the | ||
| protocol in the [TLA<sup>+</sup> formal specification language][tla+ |
There was a problem hiding this comment.
perhaps add "(Temporal Logic of Actions)" between "TLA+" and "formal" to describe the acronym without the reader needing to leave the newsletter.
There was a problem hiding this comment.
In general I do think we should expand unfamiliar abbreviations. In this case, I don't think it's useful---either people are familiar with the language or not. Those who are familiar with it either know what the abbreviation stands for or don't care about it. Those who are not familiar with TLA+ probably want to know more about it than the expansion of its abbreviation, so they're going to click the link anyway.
| There's no need[^getheaders-details] to send more than one `getheaders` | ||
| request and Bitcoin Core doesn't send more than one block announcement | ||
| in an `inv` message, so this change should have no effect when Bitcoin | ||
| Core nodes connect to Bitcoin Core peers; it's only expected |
There was a problem hiding this comment.
s/it's/its/ (as this is possessive and not a contraction)
Considering the sentence length, could also break into 2 sentences here with s/; it's/. The/
|
|
||
| - [Eclair #1395][] updates the route pathfinding used by Eclair to | ||
| factor in channel balances and to use [Yen's algorithm][]. | ||
| The PR description say that "the new algorithm consistently |
There was a problem hiding this comment.
s/say/says/ (or "According to the PR description: ")
jnewbery
left a comment
There was a problem hiding this comment.
Looks good. I just have a couple of nits.
I've pushed a commit for my write-up for Bitcoin Core n18877.
| - **Evaluate proposed changes to BIP341 taproot transaction digest:** as | ||
| described in [last week's newsletter][news97 spk commit], there has | ||
| been a request for [taproot][topic taproot] signatures to make an | ||
| additional commitment to all the scriptPubKeys of the UTXOs being |
There was a problem hiding this comment.
nit: s/all the scriptPubKeys of the UTXOs/the scriptPubKeys of all the UTXOs/ sounds slightly better to me (the first sounds to me a bit like a UTXO could include multiple scriptPubKeys).
| that uses three transactions. Dmitry Petukhov [posted][petukhov | ||
| tla+] about a [specification][sas tla+ spec] he'd written for the | ||
| protocol in the [TLA<sup>+</sup> formal specification language][tla+ | ||
| lang], helping to verify the correctness of the protocol (to a |
There was a problem hiding this comment.
This parenthetical is a little awkward. I think it can be removed.
jnewbery
left a comment
There was a problem hiding this comment.
Couple of small comments in @bitschmidty's section.
|
ACK f9a2f1e. Looks good! |
|
Thanks @bitschmidty for your section and @dongcarl for your merge summary! I made a few edits, most of which I think are self-explanatory, but two to Schmidty's section that might warrant additional explanation:
As always, please feel free to revert or edit any changes. Thanks! |
SGTM
I parenthetical too much. Change looks good. |
|
All changes look good to me. Thanks Harding! |
| - **Evaluate proposed changes to BIP341 taproot transaction digest:** as | ||
| described in [last week's newsletter][news97 spk commit], there has | ||
| been a request for [taproot][topic taproot] signatures to make an | ||
| additional commitment to the scriptPubKeys of the all the UTXOs being |
jonatack
left a comment
There was a problem hiding this comment.
Interesting reporting on a variety of client software and services 👍
| than existing protocols, it saves on transaction fees (both by using | ||
| less block space and potentially by requiring less urgency for its | ||
| settlement transactions), it only requires consensus-enforced | ||
| timelocks on one of the chains in a cross-chain swap, and that it |
There was a problem hiding this comment.
perhaps remove "that" here, as the previous clauses don't use one
| settlement transactions), it only requires consensus-enforced | ||
| timelocks on one of the chains in a cross-chain swap, and that it | ||
| doesn't depend on any new security assumptions or Bitcoin consensus | ||
| changes. If taproot is adopted, it can be used even more privately |
There was a problem hiding this comment.
ambiguous "it"
perhaps "If taproot is adopted, this proposal (or protocol) would allow it to be used even more privately..."
| - **Blockstream Satellite 2.0 supports initial block download:** | ||
| Blockstream [outlines version 2.0 upgrades][blockstream satellite v2 blog] to | ||
| their satellite service which include expanded Asia-Pacific coverage, | ||
| additional bandwidth, and an updated protocol that enabling a full node to complete an initial sync |
There was a problem hiding this comment.
remove "that", or s/enabling/enables/
|
|
||
| - **Breez wallet enables spontaneous payments:** | ||
| [Version 0.9][breez 0.9] of Breez wallet adds the ability to send spontaneous | ||
| payments to Lightning nodes that support keysend. |
There was a problem hiding this comment.
maybe?: [keysend payments][topic spontaneous payments].
There was a problem hiding this comment.
Only wanted to avoid because we used it a couple bullets earlier.
| since the first release candidate. | ||
|
|
||
| - [LND 0.10.1-beta.rc1][] is the first release candidate for the next | ||
| maintenace release of LND. |
|
|
||
| - [Bitcoin Core #18877][] is the first step towards support for serving | ||
| [compact block filters][topic compact block filters] on the P2P | ||
| network, as specified in [BIP157][]. Nodes that enabled the compact block filter index |
| `getdata` requests that specify an unknown type of data. The new | ||
| logic will also ignore requests for types of data that aren't expected | ||
| to be sent over the current connection, such as requests for | ||
| transactions on block-relay-only connections. |
There was a problem hiding this comment.
Perhaps describe or mention the change from previous behavior.
|
@jonatack thanks for that extra review! |
eae32cb to
37dcdce
Compare
|
Squashed and merged! 👍 team! Thanks to @harding @jnewbery @dongcarl for authoring and @adamjonas @jonatack for reviewing. |
Co-authored-by: hulatown(OpenClaw) <clawdius@openclaw.ai>
Bitcoin Core #18877@jnewberyC-Lightning #3614@dongcarl